home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
ietf
/
ripv2
/
ripv2-minutes-92mar.txt
< prev
next >
Wrap
Text File
|
1993-02-17
|
3KB
|
84 lines
The Minutes below should be considered a Rough Draft - 4/01/92 Megan
CURRENT_MEETING_REPORT_
Reported by Gary Malkin
RIP-V2 Working Group Minutes
Status Update
Chairperson Gary Scott Malkin / gmalkin@ftp.com
Mailing List ietf-rip(-request)@ftp.com
Date of Last meeting San Diego IETF / March 18, 1992
Date of next meeting Boston IETF / July 1992
Progress Settled on final packet format and new field
definitions. Determined that no backwards
compatibility issues exist. Made first pass
at listing the objects needed in the MIB.
Milestones:
Boston Final review of RIP-II I-D and submission into
the standards track. First review of RIP-II MIB.
Washington Review of implementations. Final review of MIB.
TBD Given successful implementation experience,
advancement of RIP-II to Draft Standard. Submission
of MIB into the standards track.
TBD Final meeting to achieve closure on any pending
issues.
Agenda
o Review of Working Group charter
o Review of newest draft document
o Discussion of backwards compatibility issues
o Discussion of security issues
o What needs to go into the MIB
The charter was accepted unchanged.
There were two changes to the packet format do to some confusion about
the Routing Domain field. The RD field, as defined, is a per packet,
user configurable parameter. It has, therefore, been moved into the
Must Be Zero field in the RIP packet header. The RD field which was in
the RIP entry has been renamed to the Route Tag. It is used to indicate
that the route was learned from an external source. The exact use of this
field is still under discussion; however, it has been determined that
the contents of the RT field must be preserved when that route is
propagated.
The subsumption of routes, made necessary by the addition of the subnet
masks is still under work. The issues accompanying supernetting were
also discussed, but no final solutions were reached. We did determine
that there should be no user controls for this, since this could lead
to black holes if routers were dis-similarly configured. It was decided
that supernetting could not be used in the presence of RIP-I routers.
It should be explicitly mentioned that next hop is an advisory value.
Next hop may also only be used for the directly connected network
over which it was received.
It was decided that addressless links would not be considered.
We will need a new route type for MIB-II.
It should be mentioned, if RFC 1058 does not, that split horizon
does not apply to routes learned via routing protocols other than RIP.